Field
The present disclosed embodiments relate generally to wireless mobile computing devices, and more specifically to power conservation in such devices.
Background
Mobile communication devices including devices such as smartphones, tablet computers, gaming devices, and laptop computers are now ubiquitous. A common and ongoing issue with these types of devices is power management. Although advances continue to be made in the areas of battery technology and hardware efficiency, current mobile device power management techniques are not adequate to meet user expectations and will almost certainly not be satisfactory in the future.
The application processor (or app processor) in many mobile wireless communication devices (or user equipment (UE)) may be suspended to conserve power. App processors are also starting to see multiple cores, thus allowing one or more cores to be idled or put into an offline state to save power. Moreover, a typical communication device has several hardware components and corresponding drivers that may be suspended during idle periods. These power saving techniques save power at the expense of processing power, an acceptable tradeoff when the app processor or other hardware components are not being fully utilized anyway.
A typical suspend and resume process includes suspending the application processor and/or other hardware if there are no pending wake locks and no wakeup source. When an interrupt is received, operation of the application processor or other hardware will be resumed. Problematically, control over suspending the application processor is based upon whether there is no wake lock or wakeup source pending. As a consequence, if there is an interrupt shortly after the suspend process is initiated, there will be additional undesirable latency to process it. Referring to FIG. 6, for example, shown is a timeline depicting this mode of operation in which a system takes X ms to complete a suspend process. As shown, if there is an interrupt after Y ms (where Y is less than X) the device takes an extra Zms to process the interrupt, which leads to poor performance (due to latencies) and suboptimal performance. Moreover, typical suspend and resume operations involve the entire system (e.g., user space, kernel drivers, and the app processor), which add substantial latency to both the suspend and resume processes.